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(54) TCP/IP header compression in X.25 networks 

(57) A process and apparatus are disclosed wherein 
a local data terminal equipment ("DTE") node which has 
the capability of using RFC 1144 TCP/IP header com- 
pression/decompression, can negotiate with an un- 152^ 
known remote DTE located at another end of a 
TCP/IP/X.25 network link, to determine if the remote 
DTE also supports RFC 1144 TCP/IP header compres- 
sion/decompression. The disclosed apparatus and proc- 
ess permits a user (such as a systems administrator, for 
example) to instruct the local DTE that a remote DTE is 
known to support TCP/IP header compression/decom- 
pression whereby the local DTE sets its routing informa- 
tion to record this information. Alternatively, the local 
DTE can automatically query an unknown remote DTE 
to determine if it supports TCP/IP header compres- 
sion/decompression and set its routing information ac- 
cordingly. J52' 
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Description 

This invention relates to the field of computer com- 
munications networks and more specifically to an im- 
proved apparatus and method for increasing the trans- 5 
mission efficiency of messages over a network which 
uses the X.25 protocol for packet switched network con- 
trol. 

Computer-to-computer communication networks 
are becoming larger and larger and message traffic on io 
these networks is increasing exponentially. It is desirable 
therefore that message transmission on these networks 
be made as efficient as possible. 

In the past, attempts have been made to develop 
specialized protocols which limit the overhead required 
in transmitting data over a local area network ("LAN") 
and to make use of certain inherent characteristics of a 
given network type to minimize the message overhead 
in a given communications session. Message overhead 
is the header information which is appended to the data 20 
portion of a message. Such header infornnatlon is nec- 
essary to permit various portions of a network to keep 
track of the administrative and procedural tasks required 
to send data from one computer to another. One meas- 
ure of overhead efficiency is the ratio of DATA to DA- 25 
TA+ HEADER. That is, the smaller the annount of HEAD- 
ER information required, the more efficient is the network 
protocol. One attempt to improve the efficiency of a pro- 
tocol is the header compression methodology outlined 
in "Compressing TCP/IP Headers for Low-Speed Serial 30 
Links," by V Jacobson, Network Working Group Re- 
quest for Comments: 1144, February 1990 (hereinafter 
"Van Jacobson" or alternatively "RFC 1144") which is 
hereby fully incorporated herein by reference. Note: 
TCP/IP is an acronym for Transmission Control Proto- 35 
col/lnternet Protocol, a suite of protocols for dealing with 
communications between heterogeneous computers. 
The TCP is responsible for breaking up the message to 
be transmitted into datagrams (i.e. a collection of data 
that is sent as a single message), reassembling them at 4o 
the other end of the communications network, resending 
anything that gets lost, and putting things back in the right 
order. The IP is responsible for routing individual data- 
grams. TCP simply hands IP a datagram with a destina- 
tion. IP doesn't know how this datagram relates to any 
datagram before it or after it. To keep track of details such 
as source and destination port numbers^ datagram se- 
quence number, checksums and other control data, TCP 
attaches a header to each datagram and hands off a 
combined header + datagramXo i P IP then adds its own 
header to this "TCPheader -1- datagram's© that the re- 
sulting packet of data looks like "IPheader + TCPheader 
+ datagram." In cases where the application is charac- 
ter-based such as telnet, riogin, or xtenm, or the ftp con- 
trol channel, the headers can be 40 bytes or more long 55 
for each byte of data transferred. The words datagram 
and packet are often used interchangeably although 
■datagram" is correctly defined as a unit of data, which 



is what the protocols deal with. A "packet" is a physical 
thing, appearing on the Ethemet or some wire. In most 
cases a packet contains one datagram. However, when 
a LAN is connected to another network such as Ethemet 
or to a PDN the TCP/IP datagram may be broken up into 
smaller pieces (if the datagram if a big file for example) 
and another header appended to each smaller piece or 
"packet". For example, when TCP/IP is used on top of 
X.25 (CCITT standard for the protocols and message 
formats that define the interface between a terminal and 
a PDN packet switching network), the X.25 interface 
breaks the datagrams up into 128 byte packets, each 
with an additional X.25 header. This is invisible to IP be- 
cause the packets are put back together again at the oth- 
er end of the communications link before passing the da- 
tagram backloTCP/IP. Nevertheless there maybe many 
more "headers" involved with such transmissions which 
do not use the TCP/IP header compression technique. 
In the case of character applications described above, 
the TCP/IP headers + data get another X.25 header at- 
tached. For more basic information about TCP/IP see 
"Introduction to Internet Protocols" by Charles L He- 
drick. Computer Sciences Facilities Group, Rutgers Uni- 
versity, July 1987. 

Present day computers are connecting LANs into 
world wide networks and typically use a PDN in some 
part of the network connection. Leased lines (the primary 
alternative to X.25 service) are more expensive and 
more difficult to obtain outside of the U.S., and are fre- 
quently non-existent across some national boundaries. 
Since X.25 is more widely used in Europe and the Far 
East than in the U. S., it is being used more heavily by 
smaller companies as well as large international compa- 
nies with world-wide offices as they become more de- 
pendent on world-wide telecommunications technology. 
There are two main characteristics which govern the cost 
of using public X.25 networks: 

1 . The charge for the use of the network is usually 
based on the amount of data sent; and 

2. The rental cost of the connection increases rapidly 
for higher speed connections. It therefore follows 
that increasing TCP/IP efficiency when using the 
PDN X.25 networks would reduce costs by 1 ) reduc- 
ing the overall amount of data sent, and 2) by pos- 
sibly using a cheaper X.25 connection because the 
total required bandwidth is decreased due to the 
header compression using the Van Jacobson 
scheme. 

Unfortunately, at the present time the Van Jacobson 
header compression scheme is not used when two sys- 
tems are communicating over an X.25 network because 
it is normally not possible to determine a priori \i a remote 
system supports the Van Jacobson compression system 
when using a packet switching system. Therefore some 
means of negotiating its use is required. 
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The present invention, as more fully described be- 
low, is a method and apparatus for negotiating the use 
of the Van Jacobson header compression/decompres- 
sk>n scheme between remote nodes in a TCP/tP/X.25 
network, thereby providing a significant reduction in the 
header data transmitted via the PDN's X.25 service, and 
for automatically storing that fact and retaining it in the 
network routing files for that session. In addition, the 
present invention provides an elegant method for imple- 
menting the use of the Van Jacobson header compres- 
sion/decompression scheme in aTCP/lP/X.25 network. 

A process and apparatus are disclosed wherein a 
local data terminal equipment ("DTE") which has the ca- 
pability of using RFC 1144 TCP/IP header compres- 
sion/decompression can communicate with an unknown 
remote DTE located atanother endof aTCP/lP/X.25 net- 
work link, to determine if the remote DTE also supports 
RFC 11 44 TCP/IP header compression/decompression. 
The disclosed apparatus and process permits a user to 
instruct the local DTE that a remote DTE is known to sup- 
port TCP/IP header compression/decompression 
whereby the local DTE sets its routing information to 
record this information. Alternatively, the local DTE can 
automatically query an unknown remote DTE to deter- 
mine if it supports TCP/IP header compression/decom- 
pression and set its routing information accordingly. 

The method for using TCP/IP header compres- 
sion/decompression in a communications.network which 
uses an X-25 packet switching link in the network in- 
cludes a process whereby a first DTE in a network issues 
' a first call request to a remote DTE. This first call request 
contains a specific communications protocol identifier 
i ("PID") in a user data field which indicates that the first 
■ DTE will use TCP/IP header compression/decompres- 
' sion The remote DTE upon sensing this PID will return 
\ either a call accept message indicating that it is also ca- 
pable of using TCP/IP header compression/decompres- 
sion, or a call clear message which indicates that it can- 
not support TCP/IP header compression/decompres- 
sion. Whichever return signal the first DTE gets from the 
remote DTE, the first DTE adjusts its internal controls to 
use or not use TCP/IP header compression/decompres- 
sion accordingly. 

The invention includes a telecommunications sys- 
tem and a DTE which uses TCP/1P/X.25 networks, and 
which has the capability of automatically determining 
whether a remote DTE can or cannot accommodate 
TCP/IP header compression/decompression. 

By way of example only, a specific embodiment of 
the present invention will now be described, with refer- 
ence to the accompanying drawings, in which:- 

Flgure 1 illustrates atypical workstation which may 
be used as a data terminal equipment (DTE) in a tele- 
communications network. 

Figure 2 illustrates a typical TCP/IP Local Area Net- 
work ("LAN") connection. 

Figure 3 illustrates atypical LAN/X.25 network con- 
figuration 



Figure 4 illustrates a typical TCP/I P/X.25 protocol 
stack arrangement. 

Figure 5 illustrates the possible TCP/IP/X.25 head- 
er-data configurations. 
5 Figure 6a illustrates the call request procedure from 

DTE A to DTE B wherein DTE B accepts the requested 
configuration. 

Figure 6b illustrates the call request procedure from 
DTE A to DTE B wherein DTE B rejects the initial call 
10 request but accepts the second call request. 

Figure 7 illustrates the location of the present in- 
vention in the environment of the SunLink X.25 version 
9.0 system. 

Figure 8 illustrates a block diagram of the RFC 1144 
IS and Call Control system of the present invention. 

Figure 9 illustrates a block diagram of the Call Re- 
quest and Response procedure of the present invention. 

Figure 10 illustrates a diagram of an X.25 packet, 
fornnat. 

20 The detailed descriptions which follow are present- 
ed largely in terms of processes and symbolic represen- 
tations of operations on data bits within a computer mem- 
- ory. These process descriptions and representations are 
the means used by those skilled in the data processing 

25 arts to most effectively convey the substance of their 
work to others skilled in the art. 

A process is here, and generally, conceived to be a 
self-consistent sequence of steps leading to a desired 
result. These steps are those requiring physical manip- 

30 ulations of physical quantities Usually, though not nec- 
essarily, these quantities take the form of electrical or 
magnetic signals capable of being stored, transferred, 
combined, compared, and otherwise manipulated. It 
proves convenient at times, principally for reasons of 

55 common usage, to refer to these signals as bits, values, 
elements, symbols, characters, temns, numbers, or the 
like. It should be bourne in mind, however, that all of 
these and similar terms are to be associated with the ap- 
propriate physical quantities and are merely convenient 

40 labels applied to these quantities. 

Further, the manipulations performed are often re- 
ferred to in terms, such as adding or comparing, which 
are commonly associated with mental operations per- 
formed by a human operator. No such capability of a hu- 

45 man operator is necessary, or desirable in most cases, 
in any of the operations described herein which form part 
of the present invention; the operations are machine op- 
erations. Useful machines for performing the operations 
of the present invention include general purpose digital 

50 computers or similar devices. In all cases there should 
be bourne in mind the distinction between the method 
operations in operating a computer and the method of 
computation itself. The present invention relates to meth- 
od steps for operating a computer in processing electri- 
cs cal or other (e.g., mechanical, chemical) physical signals 
to generate other desired physical signals. 

The present invention also relates to apparatus for 
performing these operations. This apparatus may be 



5 



EP 0 701 354 A1 



6 



specially constructed for the required purposes or it may 
comprise a general purpose computer as selectively ac- 
tivated or reconfigured by a computer program stored in 
the computer. The processes presented herein are not 
inherently related to a particular computer or other ap- 
paratus. In particular, various general purpose machines 
may be used with programs written in accordance with 
the teachings herein, or it may prove more convenient to 
construct more specialized apparatus to perform the re- 
quired method steps. The required structure for a variety 
ot these machines will appear from the description given. 

The Van Jacobson header compression system (as 
defined in RFC 1 1 44 which is incorporated herein by ref- 
erence) is a method of improving the efficiency of TCP/IP 
based applications by encoding the packet header and 
reducing its size. This results in an improvement tn the 
ratio of the number of data bytes to the total number of 
bytes sent across a network. 

While this system applies equally to any TCP/IP ap- 
plication the effect is particularly pronounced when using 
character-based applications such as telnet, riogin, or 
xterm, or the ftp control channel. In these cases. 40 
bytes of protocol information may be sent in the IP head- 
er for each byte of data transferred. In tests it has been 
found that this header compression system can improve 
the efficiency of a typical Telnet session up to 6 times. 
Currently RFC 1144 has been specified for IP/SLIP and 
IP/PPP, but todate there has been no tractable proce- 
dure for using RFC 1 1 44 in a network where a PDN X.25 
packet switching link forms a connecting part of the net- 
work link, wherein some terminals are capable of sup- 
porting header compression/decompression and some 
are not. 

A process and apparatus are disclosed wherein a 
local data terminal equipment ("DTE") node which has 
the capability of using RFC 1144 TCP/IP header com- 
pression/decompression, can negotiate with an un- 
known remote DTE located at another end of a 
TCP/IP/X.25 network link, to determine if the remote 
DTE also supports RFC 1144 TCP/IP header compres- 
sion/decompression. The disclosed apparatus and proc- 
ess permits a user (such as a systems administrator, for 
example) to instruct the local DTE that a remote DTE is 
known to support TCP/IP header compression/decom- 
pression whereby the local DTE sets its routing informa- 
tion to record this information, as more fully described 
below. Alternatively, the local DTE can automatically 
query an unknown remote DTE to determine if it supports 
TCP/IP header compression/decompression and set its 
routing information accordingly. The implementation of 
the invention, while it may be used in any relevant 
TCP/IP/X.25 network context with any computer pro- 
gram product acting as a DTE, is described in the context 
of a particular type of network control system and exem- 
plary programming systems for illustrative purposes. 
However, no specific knowledge of the illustrated system 
is required by those skilled in these arts to understand 
and implement the process and system described in this 



disclosure, using various other network systems and re- 
lated tools. This invention nnay be implemented on any 
network having some terminals which support header 
compression/decompression and some terminals which 
5 do not have such support. 

Operating Environment. 

The environment in which the present invention is 

10 used encompasses the general distributed computing 
system, wherein general purpose computers, worksta- 
tions, or personal computers are connected via commu- 
nication links of various types, in a client-server arrange- 
ment, wherein programs and data, many in the form of 

IS objects, are made available and shared by various mem- 
bers of the system for execution and access by other 
members of the system. Some of the elements of a gen- 
eral purpose workstation computer 20 are shown in Fig- 
ure 1, wherein a processor 1 is shown, having an In- 

20 put/output ("I/O") section 2, a central processing unit 
("CPU") 3 and a memory section 4. The I/O section 2 is 
connected to a keyboard 5, a display unit 6, a disk stor- 
age unit 9 and a CD-ROM drive unit 7. The CD-ROM unit 
7 can read a CD-ROM medium 8 which typically contains 

2S programs 10 and data. A computer display icon 11 is 
shown on the display unit 6. Similar workstations may be 
connected by a communications path to form a distrib- 
uted computer system and will generally be referred to 
herein as Data Terminal Equipments ("DTEs"). 

30 The present invention will be discussed below in 
terms of basic background and underlying technology to 
provide a summary of what the invention is and how it 
functions, followed by a detailed description of how to 
use the invention. 

35 

Underlying Technology 

The X.25 Protocol 

40 X.25 is a data communications protocol produced 
by the Comite Consultatif International de Telephone and 
Telegraph (CCITT), a standards making body that is part 
of the International telecommunications Union. X.25 
dates from 1 976 and is defined as being the protocol gov- 
45 erning connection between packet mode data terminal 
equipment (DTEs, the device at the user's end) and data 
circuit-termination equipment {DCEs, the device at the 
network end). X.25, like any other data communications 
protocol, specifies how data may be exchanged between 
so any two systems in a reliable flow-controlled manner. 
The protocol defines mechanism for call set-up and ter- 
mination (known as "clearing") and other functions nec- 
essary for the smooth functioning of a data communica- 
tions link. The CCITT X.25 specification describes a dis- 
ss tinct protocol to be performed by a DCE and a separate 
protocol to be performed by a DTE. Generally, Public/Pri- 
vate Data Networks ("PDNs") provide DCE implementa- 
tions of X.25, while computer vendors provide DTE im- 



45 



so 



7 



EP 0 701 354 A1 



8 



plementatbns of X.25. The CCITT X.25 recommenda- 
tion provides a full description of the X.25 protocol. The 
description of the exemplary systems used In the present 
invention nr^ke use of systems based on the 1988 
CCITT X25 specification. 

The TCP/IP Protocol 

The TCP/IP protocol was briefly defined in the Back- 
ground section and is more fully described in various 
RFCs. the most important of which have been collected 
into a three volume set titled the DDN Protocol Hand- 
book, published by SRI International, Menio Park, Cali- 
fornia 94025, and which are generally available via anon- 
ymous FTP from srl-nicarpa in files rfc:rfc -index.txt and 
rfc:rfcxxxx.txt. 

Referring now to Figure 2, a typical TCP/I P system 
20 is shown to indicate how TCP and IP are configured 
for communications and to illustrate that the total com- 
munications facility may consist of multiple networks 
("subnetworks'). Some sort of network access protocol, 
such as token ring or FDDI etc. is used to connect the 
DTE to a subnetwork. In Figure 2, a host computer 22 
aeting as a DTE contains an Operating System ("OS") 
30, applications programs 24, the host-to-host protocol 
("TCP") 26, a copy of the Internet protocol implementa- 
tion ("IP") 28 and a first network access protocol (NAP 
1 ) 32. This first network access protocol 32 enables host 
22 to send data across a first subnetwork 34 to router 
36 which contains an implementation of IP 38, a copy 
NAP1 40 of the first network access protocol 32, and a 
copy NAP2 42 of a second network access protocol 48 
which is on a second host 58 and which in general allows 
host 58 to communicate with the router 36 via a different 
subnetwork 44. The second host 58 also has an OS 46, 
applications 56, a TCP layer 52 and an IP layer 50. IP 
is implemented in all of the end systems and the routers. 
It acts as a relay to move a block of data from one host, 
through one or nrrare routers, to another host. TCP is im- 
plemented only in the end systems where it keeps track 
of the blocks of data to assure that all are delivered reli- 
ably to the appropriate application. 

One of the subnetworks which links various hosts in 
a communications system could be a PDN X.25 packet 
switching network. For example, in Figure 3 foreign host 
62 is connected to an X.25 subnetwork 64 which itself is 
connected to a SunLink X-25 gateway 68 connected to 
an Ethernet subnetwork 78, another SunLink X.25 gate- 
way 74 connected to another Ethernet subnetwork 76. 
In each of these systems (i.e. foreign host 62, SunLink 
X.25 gateway 68 and SunLink X.25 gateway 74) the pro- 
tocol stack 80 could be as shown in Figure 4. In Figure 
4 host1 82 contains Its OS 84, applications 86, a TCP 
layer 88, IP layer 90 and an X.25 network access proto- 
col layer 92 for communicating with a PDN X.25 network 
94. Host2 96 similarly has its OS 98. applications 100, 
TCP layer 1 02, IP layer 1 04 and its X.25 network access 
protocol layer 106. A gateway could have only an IP lay- 



er, and X-25 protocol layer. 

In the TCP/I P/X25 network link of Figure 4 the data 
packets sent from host (or DTE) to host (DTE) would 
generally be configured as shown in Figure 5. In the 
5 data configuration system 110 of Figure 5, a block of 
user data 112 (which is called a "datagram" and which 
could be one character or as large as 1500 octets, an 
"octet" being a term used in the Internet documentation 
to mean 8 bits because some systems use "byte" to 
10 mean more than 8 bits) is shown. This datagram 112 gets 
a TCP header 116 attached to it and becomes a TCP 
segment 114. This TCP segment 114 gets an IP header 
120 attached to it and becomes an IP datagram 118. If 
the IP datagram 114 Is less than 128 bytes it gets an 
15 x.25 header 124 attached to it and becomes an X.25 
packet 122. If however the IP datagram 128 is larger 
than 128 bytes, it gets broken up into 128 byte packets 
130-136 each with its own X.25 header. 

As indicated above, in cases where the application 
20 is character-based such as telnet, rtogin. or xterm, or the 
ftp control channel the headers can be 40 bytes or more 
long for each byte of data transferred. Efficiency and cost 
control therefore mandates that these headers be mini- 
mized wherever possible, and the currently most effec- 
ts tive TCP header compression scheme known is the Van 
Jacobson scheme. The need therefore is for a method 
to permit two unknown hosts on an TCP/iP/X.25 link to 
use the Van Jacobson TCP header compression/decom- 
pression scheme wherever possible. 

30 

The Invention 

In the preferred embodiment, a method and appa- 
ratus for negotiation between two hosts/DTEs is imple- 

35 mented within the framework of the system called Sun- 
Link® X.25 a product of Sun Microsystems® Inc. the as- 
signee of the. present invention. (SUN,. SUN^ MICRO- 
SYSTEMS and SUNLINK are registered trademarks of 
Sun Microsystems Inc.). However those skilled in the 

40 arts will recognize that the method of the present inven- 
tion may be implemented in any programming language, 
in any computer, DTE, communications system, and/or 
network access process making use of the TCP/IP and 
X.25 protocols or any network wherein some terminals 

45 can support header compression/decompression and 
some cannot. 

There are two methods for determining the use or 
non-use o1 the Van Jacobson TCP header compres- 
sion/decompression by a remote DTE on a TCP/IP/X.25 

so network link: 

1 ). As part of he routing information contained in a 
local host (ie. a DTE) it will be specified whether or 
not a remote system is known to support the TCP 
ss header compression/decompression scheme. In the 
preferred embodiment this information is stored in a 
routing table which is used to select links and SNPA 
addresses based on higher level addresses. Alter- 
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natively, such data could be stored in an existing 
routing table for X.25 or in a special routing table for 
this purpose only. This information can be supplied 
by a system administrator, or determined automati- 
cally as indicated below. 

2). In the preferred embodiment the system/DTE ini- 
tiating a call will use a specified Protocol identifier 
("PID") in the User Data Field (516 in Figure 10) of 
the Call Request Packet 500, to indicate that IP 
using RFC 1144 (the Van Jacobson scheme) is in 
use. The PI D occupies the first one or more bytes of 
the User Data area 51 6. For example, in the case of 
a PID = CC the User Data might be only a single 
byte containing the CC. In a preferred embodiment 
the specific PID has the value OXEF. If this Call 
Request containing the specific PID is refused by the 
remote system/DTE then a second call request will 
be attempted with the PID set to OXCC, the standard 
PID for uncompressed TCP/IP. Whether the use of 
the compression scheme is agreed to or not the rout- 
ing table specified in 1 above should be updated. 
The negotiation process 1 50 in Figure 6 depicts the 
method just described. In Figure 6a a first sys- 
tem/DTE 152 sends a Call Request packet contain- 
ing the specific PID 154 to a remote systenn/DTE 
156. The remote system/DTE 156 sensing the spe- 
cific PID and confirming that it is adapted to support 
TCP/IP header compression/decompression, it 
would return a Call Accept 1 58 packet to the origi- 
nating system/DTE 152. In Figure 6b, again a first 
system/DTE 1 52 sends a Call Request packet con- 
taining the specific PID 154 to a remote system/DTE 
160. This remote system/DTE 160 does not under- 
stand the specific PID 154 and therefore returns a 
Call Clear 1 62 packet. On receipt of the Call Clear 
1 62 packet the first system/DTE 1 52 recognizes that 
the remote systenn/DTE 16 cannot support the 
TCP/IP Header compression/decompression 
scheme and therefore decides to see if remote sys- 
tem/DTE 160 can accept uncompressed TCP/IP 
data over this X.25 network link. Originating sys- 
tem/DTE 152 replaces the specific PID (PID=OxEF) 
with the standard PID (PID=OxCC) and sends 
another Call Request packet 164. If remote sys- 
tenn/DTE 160 can accept uncompressed TCP/IP 
data over this X.25 network link then the remote sys- 
tem/DTE 160 returns a Call Accept packet 166 and 
the link is established. 

in a preferred embodiment this Call Control negoti- 
ation and RFC 1144 control is implemented as an aug- 
mentation to an "IP to X.25 Encapsulation" module 
("IXE"). Referring now to Figure 7 the preferred embod- 
iment of the present invention is illustrated in the context 
of SunLink X.25 version 9.0 200. In Figure 7 an IP mod- 
ule 206 feeds data to the IXE module 212 via link 208. 
The IXE module 212 using the routing table 21 6 and the 



configuration tool 214 allows IP to run over X.25 and in- 
cludes support for the Defense Data Network's ("DDN") 
X.25 Standard Service. The IXE module 212 is connect- 
ed to the "RFCII 44 and Call Control" module 21 8 which 

5 performs the Van Jacobson header compression/de- 
compression if appropriate, as well as the determination 
upon message initiation, of whether the Jacobson head- 
er compression/decompression process is appropriate 
between two specific communicating locations. The RFC 

10 1144 and Call Control module 218 is connected to the 
'•X.25 Packet Layer Protocol" module 220 which itself 
has connections to both a "Link Access Procedure- Bal- 
anced" ("LAPS") module 238 and a "Logical Link Con- 
trol, type 2" (-LLC2") module 240. The LAPB module 238 

1^ provides layer 2 of X.25 for Wide Area Networks 
("WANs"), and the LLC2 module 240 provides a "con- 
nection-oriented" operation which allows X.25 to run 
over Local Area Networks ("LANs"). 

The IXE, X.25 PLP, LAPB and LLC2 modules imple- 

20 nnent protocols and procedures that are well known in 
the art and are described generally without specific de- 
tail. 

iXE (iP to X.25 Encapsulation) 

25 

This module is basically an M-to-N multiplexor 
("mux"). This mux allows IP to run over X.25 and allows 
for both static stnd dyna/n/c connections. Sfaf/c connec- 
tions are such that X.25 connections are always up, 

30 whereas dynam/c connections are those where the X.25 
connection is brought down after a user specified 
amount of idle time . On the upper side of the IXE module 
(212 in Fig.7) there is one stream for each IP subnet 
using X.25 208, 210. On the lower side there is one 

35 stream per "Virtual Circuit" ("VC") 236, 234. The 
STREAMS interfaces to this module are "connectionless 
Data Link Provider Interface" ("DLPI") (UNIX Internation- 
al's interface to layer 2) on the upper side of the module 
208, 210, and "Network Layer Interface" ("NLI") (a Sun 

40 Microsystems, Inc. interface to layer 3) 236, 234, is used 
on the lower side of the IXE module 21 2. Any appropriate 
interface to protocol layer 3 which is well known in the 
art may be used in place of NLI. STREAMS or the 
Stream I/O system was originally designed for the 8th 

45 Edition of Research UNIX by Dennis Richie and is well 
known in the art and will not be described further herein. 
See, for example, "UNIX Network Programming" by W. 
Richard Stevens, PTR Prentice Hall, 1990, pages 
374-378. 

so 

X.25 PLP (Packet Layer Protocol). 

The X.25 PLP module 220 is an M-to-N mux. On the 
upper side 236,234 there is one stream per Virtual Cir- 
55 cuit. (There can also be streams used for management 
purposes). On the lower side of the X.25 PLP module 
220 there is one stream per link (WAN or LAN) 242, 244. 
The Streams interfaces are NLI on the upper side 234, 
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236 and "Sun Microsystems. Inc.'s Link Layer Interface' 
("SLI") on the lower side 242, 244 of the module. SLI is 
an interface to Protocol Layer 2. This Protocol Layer 2 is 
well known in the art and any Interface mechanism to 
create an interface from the X-25 PLP module 220 to 
Layer 2 would be equivalent. DLPI would be a well known 
alternative interface to the SLL 

LAPB 

The LAPB module 238 is a Streams mux. This mux 
supports both the LAP and LAPB protocols. On the upper 
side 242 there is one stream per WAN link, and on the 
lower side (not shown in Fig. 7) there is one stream per 
link as well. No multiplexing occurs in this module. There 
can also be additional streams to the upper side for trac- 
ing, and for statistics gathering. The STREAMS interfac- 
es are: SLI on the upper side 242 and Sun's WAN driver 
interface on the lower side (not shown). This mux may 
also be adapted in the future to use the connection-ori- 
ented DLPI interface on the upper side and may be 
adapted to run under the ISDN B-channel protocol stack, 
as well as under X.25 PLP. 

LLC1/2 

This STREAMS driver (an M-to-1 mux) supports 
both LLC1 and LLC2. Only LLC2 is needed for X.25. but 
LLC1 is needed for running the ConnectionLess Network 
Protocol ("CLNP") over LANs. The CLNP and its Con- 
nectionLess Network Service ("CLNS") is the Open Sys- 
tems Interconnection ("OSl") protocol equivalent of IP. 
On the upper side of the mux 244 there can be one 
stream per Service Access Point (''SAP")/LAN connec- 
tion pair For example, if there is only one protocol, like 
X. 25, registered with an LLC at a SAP. and there are 
two LAN devices underneath, there will be two active up- 
' per streams to the LLC mux. There are separate streams 
for LLC 1 and LLC2 per SAP. On the lower side there is 
one stream per LAN driver. If there are multiple LAN driv- 
ers, LLC1/2 is an M-to*N mux. The STREAMS interfaces 
are: SLI and DLPI (connection-oriented for LLC2 and 
connectionless tor LLC1 ) on the upper side, and con- 
nectionless DLPI on the lower side. The support for the 
SLI interface may be replaced by the X.25 mux adapted 
to DLPL 

The Invention Details 

Referring now to Figures 8 & 9, a flow chart of the 
presently preferred embodiment of the method of the in- 
vention 300 as it operates within the RFC 11 44 and Call 
Control module is now described. In Figure 8 the proc- 
ess begins as IP/X.25 traffic 302 is detected. It is first 
determined whether there is an existing suitable X.25 
connection for this message 304. If there is 306 then the 
existing connection is used 308 and the data transfer is 
effected 356 with the processing thereafter as a normal 



X.25 call. If there was not an existing suitable X.25 con- 
nection for this message 31 2, the "config" file is checked 
314 to determine "use of compression' is indicated in 
this file. The "config' file is the main, global configuration 

5 rileforalllPoverX.25connections. If use of compression 
is not indicated in the config file 316 then an attempt is 
made to establish a standard (I.e. no header compres- 
sion) X.25 connection using the standard PID 'CG" 346. 
If the remote terminal accepts the 'CC' connection 350 

10 then the routing table Is updated with that fact and the 
data transfer continues 356. If use of compression is in- 
dicated in the config file 320. a further test is made to 
determine whether the "always try compression" flag is 
set 322 in the config file. If so 324 then an attempt is 

IS made to establish a connection using a PID set to "EF" 
334. If the connection is accepted 342 then the "routing" 
file is updated 344 to add an entry to this file if one does 
not exist for the remote host or to overwrite the existing 
entry for that host if one does exist. Again the data trans- 

20 fer step 356 is then executed as before. If the remote 
host does not accept the connection using the PID=EF 
338 the routing table is updated to reflect this fact 340 
and the PID is changed to "CC" and the connection at- 
tempted again 346. This leg of the process continues as 

25 described before. Back at step 322 if the "always try 
compression" flag in the config file is not set 326, the 
"routing" file is tested 328. This "routing" file contains in- 
fornnation about routes to individual hosts, including 
whether or not compression is supported by a given host. 

30 If the routing file indicates that the particular host sup- 
ports compression 332 then the system sets the PID 
equal to EF and the connection is attempted 334 as de- 
scribed above. If the routing file indicates that the partic- 
ular host does not support compression 330 then the 

35 system sets the PID equal to CC and the connection is 
attempted 346 as described above. In those cases 
where the CC connection, that is the standard non-com- 
pression X.25 connection, is not accepted 352 the sys- 
tem returns a signal error 354 to the requesting host in- 

40 dicating that the connection cannot be made. 

Based upon the PID settings and related flags In the 
routing table, the data transfer 356 process then includes 
processes which test to see if the message is incoming 
in which case the header may be decompressed, or if 

45 the message is outgoing the header would or would not 
be compressed depending on the compression support 
indicated by the flags. This is accomplished as follows: 
within the Data Transfer section 356 the "Compression 
in use" flag is tested 360, and if it is set to "yes" 362 and 

so the data is incoming from X.25 data 368 the header is 
decompressed 380 and passed to IP 384. If the "Com- 
pression in use" flag is set to "yes" 362 and the data is 
outgoing to X.25 data 370 the header is compressed 382 
and passed to X.25 processing 390. If the "Compression 

55 in use" flag is tested 360. and if it is set to "no" 364 and 
the data is incoming from X.25 data 386 the data is 
passed to IP 384. If the "Compression in use" flag is set 
to "no" 364 and the data is not incoming from X.25 data 
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388 the data is passed to X25 processing 390. 

While the present invention has been described with 
references to Figures 1-10, it will be appreciated that 
the figures are for illustration only, and are not to be taken 
as limitations on the present invention. Similarly, the 
present embodiment of the invention has been described 
in terms of specific programs, modules, protocol inter- 
faces between modules and other specific implementa- 
tions and it will be appreciated by those skilled in these 
network systems arts that these specifics are for illustra- 
tion only, and are not to be taken as limitations on the 
present invention. 



Claims 

1. A method for using header compression/decom- 
pression in a communications network which 
includes one or more nodes which support said 
header compression/decompression and one or 
more nodes which do not support said header com- 
pression/decompression, a node containing a com- 
puter system which includes a processor, memory 
and program instructions, the method being imple- 
mented by said program instructions and comprising 
the steps of: 

initiating a first call request to a remote data 
terminal equipment (DTE) over network link, said 
first call request being issued by a local DTE; 

assigning a specific protocol identifier (PID) 
associated with said first call request to indicate that 
said local DTE is capable of using header compres- 
sion/decompression; 

returning a message by said remote DTE to 
said local DTE to indicate whether said remote DTE 
is adapted to support header compression/decom- 
pression, and 

using said header compression/decompres- 
sion in said network link if said remote DTE indicates 
that said remote DTE can support said header com- 
pression/decompression. 

2. The method described in claim 1 comprising the 
additional steps of: 

said local DTE changing said specific PID to a 
standard PID which indicates that a standard 
uncompressed header is being used, if said remote 
DTE Indicates no support for header compres- 
sion/decompression; 

transmitting a second call request to said 
remote DTE containing said standard PID; 

said remote DTE returning a message to said 
local DTE to indicate that said remote DTE will 
accept a standard uncompressed header; and 

using said communications protocol without 
header compression in said network link for commu- 
nications between said local DTE and said remote 
DTE. 
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3. The method described in claim 1 or claim 2. wherein 
said header ccmpression/decompression is TCP/IP 
header compression/decompression. 

5 4. The method described in claim 3 wherein said 
TCP/IP header compression/decompression using 
the header compression/decompression scheme 
described in RFC 1144. 

5. The method described in any of claims 1 to 
4, wherein said network link includes an X.25 net- 
work link. 

6. A method for using TCP/IP header compres- 
is sion/decompression in a communications network 

which uses an X.25 packet switching link, and which 
includes one or more nodes which support said 
header compression/decompression and one or 
more nodes which do not support said header com- 
20 pression/decompression, a node containing a com- 
puter system which includes a processor, memory 
and program instructions, the method being imple- 
mented by said program instructions and comprising 
the steps of: 

2S initiating a first call request to a remote data 

terminal equipment (DTE) over a TGP/IP/X.25 net- 
work link, said first call request being issued by a 
local DTE; 

using a specific protocol identifier (PID) in a 
30 user data field of a call request packet containing 
said first call request to indicate that said local DTE 
is using TCP/IP header compression/decompres- 
sion; 

returning a message by said remote DTE to 
35 said local DTE to indicate whether said remote DTE 
is adapted to support TCP/IP header compres- 
sioon/decompression; and 

using said TCP/IP header compres- 
sion/decompression in said TCP/I P/X. 25 network 
40 link if said remote DTE indicates that said remote 
DTE can support said TCP/IP header compres- 
sion/decompression. 

7. The method described in claim 6 comprising the 
45 additional steps of: 

said local DTE changing said specific PID to a 
standard PID which indicates that a standard 
TCP/IP uncompressed header is being used, if said 
remote DTE indicates no support for TCP/IP header 
so compression/decompression; 

transmitting a second call request to said 
remote DTE containing said standard PID; 

said remote DTE returning a message to said 
local DTE to indicate that said remote DTE will 
55 accept a standard TCP/IP uncompressed header; 
and 

using TCP/IP without header compression in 
said TCP/I P/X. 25 network link for communications 
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between said local DTE and said remote DTE. 

8. The method described in claim 6 or claim 7 compris- 
ing the additional step of updating a routing table in 
said local DTE to indicate whether said remote DTE s 
supports TCP/IP header compression/decompres- 
sion or not. 

9. The method described in any of claims 6 to 8, com- 
prising the additional step of updating a routing table io 
in said local DTE with a specific indicator value to 
indicate whether said remote DTE supports TCP/IP 
header ccmpression/decompression or not, said 
specific indicator value being settable by a systems 
administrator prior to sending said first call request i5 
and said specific indicator value being settable by 
said local DTE as a result of said message returned 

by said remote DTE in response to said first call 
request. 

20 

10. A telecommunications system comprising: 

a local data terminal equipment (DTE) com- 
prising a processor, a memory, a program in said 
memory, said program including instructions for con- 
trolling communications; 25 

a remote DTE, connected to said local DTE 
through a network link, said network link comprising 
one or more DTEs which can support use of mes- 
sage header compressior>/decom press ion and one 
or more terminals which cannot support said use of 30 
message header compression/decompression; 

a first device in said local DTE adapted to 
transmit a first call request to said remote DTE over 
said network link, wherein said first call request is 
adapted to contain a specific protocol identifier (PID) 35 
containing said first call request, said specific PID 
indicating that said local DTE. supports use of mes- 
sage header compression/decompression; 

a second device in said remote DTE adapted 
to recognize a PID in said first call request and to 40 
respond to said local DTE. with a message which 
indicates whether said remote DTE is adapted to 
support said message header compression/decom- 
pression or not. 

45 

11. The telecommunications system defined in claim 10 
wherein said network link is a TCP/TP/X.25 link. 

12. The telecommunications systems defined in claim 

10 or claim 11 wherein said message header com- so 
pression/decpmpression is TCP/IP header com- 
pression/decompression. 

1 3. The telecommunications system described in any of 
claims 10 to 12 wherein said local DTE can change ss 
said specific PID to a standard PID which indicates 
that an uncompressed header can be used, if said 
remote DTE has indicated no support for message 



header compression/decompression, and said local 
DTE can further transmit a second call request to 
said remote DTE containing said standard PID. 

1 4. The telecommunications system described in any of 
claims 10 to 1 3 wherein said remote DTE can return 
a message to said local DTE to indicate that said 
remote DTE will accept an uncompressed header 

1 5. A telecommunications system comprising: 

a local data terminal equipment (DTE) com- 
prising a processor, a memory, a program in said 
memory, said program including instructions for con- 
trolling communications; 

a remote DTE, connectable to said local DTE 
through a TCP/IP/X.25 network link, said network 
link comprising one or more DTEs which can support 
use of TCP/IP header compression/decompression 
and one or more terminals which cannot support 
said use of TCP/IP header compression/decom- 
pression; 

a first device in said local DTE adapted to 
transriiit a first call request to said remote DTE over 
said TCP/IP/X.25 network link, wherein said first call 
request contains a specific protocol identifier (PID), 
said specific PID indicating that said local DTE sup- 
ports use of TCP/IP header compression/decom- 
pression; 

a second device in said remote DTE which can 
recognize said specific PID in said first call request 
and respond to said local DTE with a message which 
indicates whether said remote DTE supports use of 
TCP/IP header compression/decompression or not. 

16. The telecommunications system described in claim 
15 wherein said local DTE can use said TCP/IP 
header compression/decompression in said 
TCP/IP/X.25 network link if said remote DTE indi- 
cates that said remote DTE can support said TCP/IP 
header compression/decompression. 

1 7. The telecomunications system described in claim 1 5 
or claim 1 6 wherein said local DTE can change said 
specific PID to a standard PID which indicates that 
a standard TCP/IP uncompressed header is being 
used, if said remote DTE has indicated no support 
for TCP/IP header compression/decompression, 
and said local DTE can transmit a second call 
request to said remote DTE containing said stand- 
ard PID. 

18. The telecommunications system described in claim 
17 wherein said remote DTE is can return a mes- 
sage to said local DTE to indicate that said remote 
DTE will accept a standard TCP/IP uncompressed 
header. 

19. The telecommunications system described In claim 
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18 wherein said local DTE can comnnunicate with 
said remote DTE using TCP/IP without header com- 
pression in said TCP/1 P/X.25 network link upon 
receiving said message indicating that said remote 
DTE will accept a standard TCP/IP uncompressed 
header. 

20. The telecommunications system described in any ot 
claims 15 to 19 wherein said local DTE can update 
a routing table in said local DTE to indicate whether 
said remote DTE supports TCP/IP header compres- 
sion/decompression or not. 

21 . The telecommunications system described in any of 
claims 15 to 20 wherein said local DTE can update 
a routing table in said local DTE with a specific indi- 
cator value to indicate whether said remote DTE 
supports TCP/IP header compression/decompres- 
sion or not, said specific indicator value being set 
prior to sending said first call request or said specific 
indicator value being set by said local DTE as a 
result of said message returned by said remote DTE 
in response to said first call request. 

22. A local data terminal equipment (DTE) including a 
processor, a memory, a program in said memory, 
said program including instructions for controlling 
communications, said DTE comprising: 

a first device in said local DTE which can trans- 
mit a first call request to a remote DTE over a net- 
work link, wherein said first call request contains a 
specific protocol identifier (PID), said specific PID 
indicating that said local DTE supports use of mes- 
sage header compression/decompression, said net- 
work link comprising one or more DTEs which can 
support use of message header compres- 
sion/decompression and one or more terminals 
which cannot support said use of message header 
compression/decompression; 

a second device in said local DTE which can 
recognize a message from said remote DTE which 
indicates whether said remote DTE supports said 
message header compression/decompression or 
not. 

23. The local DTE described in claim 22 wherein said 
network link is a TCP/IP/X25 link. 

24. The The local DTE described in claim 22 or claim 23 
wherein said message header compression/decom- 
pression is TCP/IP header compression/decom- 
pression. 

25. The local DTE described in any of claims 22 to 24 
wherein said local DTE can change said specific PID 
to a standard PID which indicates that an uncom- 
pressed h eader can be used, if said remote DTE has 
indicated no support for message header compres- 
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sion/decompressbn, and said local DTE can further 
transmit a second call request to said remote DTE 
containing said standard PID. 

5 26. The local DTE described in any of claims 22 to 25, 
wherein said remote DTE can return a message to 
said local DTE to indicate that said remote DTE will 
accept an uncompressed header. 

10 27. A local data terminal equipment (DTE) including a 
processor, a memory, a program in said memory, 
said program including instructions for controlling 
communications, said DTE comprising: 

a first device in said local DTE which can trans- 

is m it a first call request to a remote DTE over a 

TCP/I P/X.25 network link, wherein said first call 
request can contain a specific protocol identifier 
(PID), said specific PID indicating that said local 
DTE supports the use of TCP/IP header compres- 

20 sion/decompresston, said network link comprising 
one or more DTEs which can support use of TCP/IP 
header compression/decompression and one or 
more terminals which cannot support said use of 
TCP/IP header compression/decompression; 

25 a second device in said local DTE which can 

recognize said a message from said remote DTE 
which indicates whether said remote DTE supports 
TCP/IP header compression/decompression or not. 

30 28. The local DTE described in claim 27 wherein said 
local DTE can use said TCP/IP header compres- 
sion/decompression in said TCP/I P/X.25 network 
link if said remote DTE indicates that said remote 
DTE can support said TCP/IP header compres- 
35 sion/decompression. 

29. The local DTE described in claim 27 or 28 wherein 
said local DTE can change said specific PID to a 
standard PID which indicates that a standard 

40 TCP/I P uncompressed header is being used, if said 
remote DTE has indicated no support for TCP/IP 
header compression/decompression, and wherein 
said local DTE can transmit a second call request to 
said remote DTE containing said standard PID. 

45 

30. The local DTE described in any of claims 27 to 29 
wherein said local DIE can communicate with said 
remote DTE using TCP/IP without header compres- 
sion in said TCP/IP/X.25 network link upon receiving 

so said message indicating that said remote DTE sup- 
ports a standard TCP/IP uncompressed header 

31. The local DTE described in any of claims 27 to 30 
wherein said local DTE can update a routing table 

55 in said local DTE to indicate whether said remote 
DTE supports TCP/IP header compression/decom- 
pression or not. 
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32. The local DTE described in any of claims 27 to 31 
wherein said local DTE can update a routing table 
in said local DTE with a specific indicator value to 
indicate whether said remote DTE supports TCP/IP 
header compression/decompression or not, said s 
specific indicator value being set prior to sending 
said first call request or said specific indicator value 
being set by said local DTE as a result of said mes- 
sage retumed by said remote DTE in response to 
said first call request. 
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